In order to ease debugging of embedded software, it is known for many modern systems on chip (SoCs) to comprise dedicated hardware trace modules. Such hardware trace modules allow non-intrusive program tracing and data accesses tracing on virtual buses (between cores and caches), whereby program changes of flow or data accesses are reported in the form of trace messages, which may be sent on a dedicated trace port to an external debugger, or stored within embedded memory for later retrieval. Known debugging interface standards include Nexus™ (IEEE-ISTO 5001-2003) and ARM's™ Embedded Trace Macrocell™ (ETM). It is also known for hardware trace modules to comprise direct memory access (DMA) capability, enabling a host debugger to read from and write to buffers.
FIG. 1 illustrates an example of an SoC 100 comprising a known hardware trace module 110. The hardware trace module 110 is operably coupled to a virtual bus 125 between, for the illustrated example, a core element 120 and a data buffer in the form of a cache 130. The hardware trace module 110 is able to trace program changes of flow and/or data accesses between the core 120 and the cache 130. Upon detection of such a program change of flow and/or data access, the hardware trace module 110 generates a trace message that is then able to be used by a debugging tool 140 to monitor execution of software by the system 100. For example, the hardware trace module 110 may be operably coupled to a dedicated trace port 150, via which the hardware trace module 110 may directly output the trace message to the external debugging tool 140. Alternatively, the hardware trace module 110 may be operably coupled to a virtual trace buffer located within an area of system memory 160, or a dedicated trace buffer 170, and the hardware trace module 110 may output trace messages to the virtual/dedicated trace buffer for subsequent retrieval by the debugging tool 140.
Known hardware trace modules suffer from a number of limitations. For example, known hardware trace modules, such as the hardware trace module 110 of FIG. 1, trace changes of program flow or data accesses on a virtual bus 125 between a system element, such as a core 120, and a data buffer. Accordingly, trace messages are only generated on read/write accesses for the data buffer made by that system element. For data buffers that are dedicated to the system element, such as cache 130, the generation of trace messages only on read/write accesses made by that system element may be sufficient for an external debugger to accurately monitor the content of the data buffer as seen by the that system element during software execution. However, for shared data buffers 180, such as comprising DMA functionality or hardware accelerators 190, the generation of trace messages only on read/write accesses by, say, a core element 120 is not sufficient to accurately observe the content of the shared data buffers, since read/write accesses performed other than by the core element will not be traced. This can significantly complicate debugging, in particular with respect to hardware/software partitioning and hardware accelerators.
In an attempt to overcome this limitation and to provide a more complete system picture during debugging, it is known to provide an SoC with multiple hardware trace modules. For example, and as illustrated in FIG. 2, a first hardware trace module 110 for monitoring a core element may be operably coupled to a virtual bus 125 between a core element 120 and a data buffer in the form of cache 130, in the same manner as for the example of FIG. 1. An additional hardware trace module 210 is operably coupled to a shared bus 220 that provides system elements with access to system memory 160, and in particular to the shared buffer 180 therein. In this manner, the additional hardware trace module 210 is able to monitor read/write accesses to the shared buffer 180 by system elements other than the core 110, enabling the content of the shared buffer 180 to be more accurately traced as compared with the example of FIG. 1. However, the need for additional hardware trace modules to provide a more complete system picture adds cost and complexity to the system, and takes up valuable space within the SoC/integrated circuit.
Another limitation of known hardware trace modules is that trace messages only contain the data accessed. For example, in the case of a 32 bit access to a 1 k bit buffer, only the 32 bits of data access are reported within the trace message. The rest of the content of the 1 k bit buffer is not reported. As a result, only a limited representation of the content of the buffer is available to a debugging tool, thereby limiting the ability of the debugging tool to provide a more complete system picture.